home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000210_news@columbia.edu_Mon Nov 21 08:28:35 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA19969
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 21 Nov 1994 08:28:35 -0500
  3. Received: by apakabar.cc.columbia.edu id AA16140
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 21 Nov 1994 08:28:33 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!quagga.ru.ac.za!ee.und.ac.za!ticsa.com!soren.aztec.co.za!soren
  6. From: soren@aztec.co.za (Soren Aalto)
  7. Newsgroups: comp.protocols.kermit.misc,alt.winsock
  8. Subject: Re: winsock/pkt dvr hack possible?
  9. Date: Mon, 21 Nov 1994 15:26:45
  10. Organization: Linkdata
  11. Lines: 24
  12. Message-Id: <soren.222.000F72A1@aztec.co.za>
  13. References: <3a67j8$j39@Mercury.mcs.com> <Pine.SUN.3.91.941118031532.9000A-100000@soleil> <3aiudg$pil@apakabar.cc.columbia.edu> <3anvci$dut@relay.tor.hookup.net> <1994Nov20.105834.33349@cc.usu.edu>
  14. Nntp-Posting-Host: soren.aztec.co.za
  15. X-Newsreader: Trumpet for Windows [Version 1.0 Rev A]
  16. Xref: news.columbia.edu comp.protocols.kermit.misc:1154 alt.winsock:22527
  17. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  18.  
  19. In article <1994Nov20.105834.33349@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  20.  
  21. >>>A packet driver on top of winsock makes no sense since winsock is not 
  22. >>>protocol independent.  The best you could possibly hope for would be a 
  23. >>>Telnet redirector for Windows DOS Sessions which communicates through 
  24. >>>WinSock.
  25. >> 
  26. >> Actually, it could probably be done by filtering out the non TCP/IP
  27. >> functionality, but it would be a very complicated bit of engineering.
  28. >> You would likely have to write some nasty DOS interrupt redirection
  29. >> code which would allow the DOS program to communicate directly to a native Windows 
  30. >> WINSOCK application via the packet driver interrupt.  The WINSOCK application 
  31. >> would act as a type of pass-through tunnel for the DOS application.  This may 
  32. >> require the use of a custom VXD, I'm not sure.  I briefly looked into this but I 
  33. >> have decided that my skill sets are not quite at a level required for this task.
  34. >-------
  35. >        Jeff is correct. The top of a sockets API is a TCP stream channel of
  36. >bytes, not packets. "It could be done..." means creating a second TCP/IP
  37. >stack feeding from the streams channel and packaging it into TCP/IP over
  38. >Ethernet frames to be passed to the application. Not very desirable, nor 
  39. >realistic.
  40.  
  41. ...but is similar to what is done inside TIA, if I am not mistaken.
  42.